SET used to be parsed as a "command", correct? and as such, you could basically write anything following it.

This PR breaks parsing valid SET statements, e.g.

Postgres:

SET application_name TO "app_admin"
SET SESSION application_name TO "app_admin"
SET LOCAL application_name = "app_admin"

Syntax:

SET [ SESSION | LOCAL ] configuration_parameter { TO | = } { value | 'value' | DEFAULT }
SET [ SESSION | LOCAL ] TIME ZONE { value | 'value' | LOCAL | DEFAULT }

Reference: https://www.postgresql.org/docs/current/sql-set.html

TSQL in general:

SET QUOTED_IDENTIFIER ON
SET QUOTED_IDENTIFIER, ANSI_NULLS ON

Reference: https://learn.microsoft.com/en-us/sql/t-sql/statements/set-statements-transact-sql?view=sql-server-ver16#considerations-when-you-use-the-set-statements

That's correct - this will break parsing of SET in many dialects. This PR also opens the door for actually parsing SET in those dialects.

Two options:

1. Implement SET parsing in Postgres, TSQL, etc
2. Make the base Tokenizer/Parser keep SET as a Command, and only switch it to a Statement in dialects that have parsing implemented

can you implement #2 for now?

I'll be out all day today and did this in a rush:
#676

Feel free to take over/merge.

ok i'll take over thanks!